Usenet 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / answers / C-faq / diff < prev next >

Wrap

Internet Message Format | 1993-05-03 | 29.0 KB

Path: senator-bedfellow.mit.edu!adam.mit.edu!scs From: scs@adam.mit.edu (Steve Summit) Newsgroups: comp.lang.c,comp.answers,news.answers Subject: comp.lang.c Changes to Answers to Frequently Asked Questions (FAQ) Followup-To: poster Date: 3 May 1993 13:53:46 GMT Organization: none, at the moment Lines: 693 Approved: news-answers-request@MIT.Edu Message-ID: <1s385aINNroo@senator-bedfellow.MIT.EDU> Reply-To: scs@adam.mit.edu NNTP-Posting-Host: adam.mit.edu X-Archive-name: C-faq/diff Xref: senator-bedfellow.mit.edu comp.lang.c:69641 comp.answers:610 news.answers:8131 Archive-name: C-faq/diff Comp-lang-c-archive-name: C-FAQ-list.diff This article contains changes between the previous revision of the comp.lang.c frequently-asked questions list (posted on April 1, last modified on February 1) and the new one. (Do _not_ worry if you have not seen the new one yet; it's coming up next.) As usual, these diffs have been edited for readability, and are not suitable for use with the patch program. This release, as you'll see, represents another fairly large set of additions. The list is up to about 122k, and my formerly steadfast resolve to keep it in one piece is flagging. (Some sites aren't receiving it, and its size is a likely factor.) I am on the brink of splitting it up; if you'd like to encourage (or discourage!) this move, now would be a good time to do so. As I mentioned last month, I am trying to track down propagation problems -- if your site receives this message and/or the abridged FAQ list but not the full, 122k FAQ list, please let me know (and, if possible, please include a header, or at least the Path: line, from one of the messages you do receive). As always, I am actively soliciting feedback on the FAQ list. If you feel that it isn't doing its job well (because of its size, or the level or tone of its answers), or if you think that it could be improved in some way, please let me know. I can't promise to make major changes, but I do promise to listen. (On the other hand, sometimes I tinker with the list too much -- if you feel it's fine as it is, I always love to hear that, too :-) .) One change I'm contemplating making (after noticing how handy it is in several FAQ lists which I've had occasion to consult recently) is a full table of contents, listing questions only. This was suggested long ago, but I always felt that it would increase the list's size unacceptably (which it would). I'm now thinking of posting the table of contents as a separate article -- although this has the obvious drawback that, if downloading FAQ lists is a chore (which it certainly can be), once you've found a question in the TOC, you have another downloading chore before you can find the answer. If you think that posting a separate TOC is a particularly good (or bad) idea, let me know. ========== < [Last modified February 1, 1993 by scs.] --- > [Last modified May 2, 1993 by scs.] ========== > The Eclipse MV series from Data General has three > architecturally supported pointer formats (word, byte, and bit > pointers), two of which are used by C compilers: byte pointers > for char * and void *, and word pointers for everything else. > > The CDC Cyber 180 Series has 48-bit pointers consisting of a > ring, segment, and offset. Most users (in ring 11) have null > pointers of 0xB00000000000. ========== > 1.15: What does a run-time "null pointer assignment" error mean? How > do I track it down? > > A: This message, which occurs only under MS-DOS (see, therefore, > section 16) means that you've written, via a null pointer, to > location zero. > > A debugger will usually let you set a data breakpoint on > location 0. Alternately, you could write a bit of code to copy > 20 or so bytes from location 0 into another buffer, and > periodically check that it hasn't changed. ========== < It is important to remember that a reference like x[3] generates --- > It is important to realize that a reference like x[3] generates different code depending on whether x is an array or a pointer. ========== "Equivalence" refers to the following key definition: > An lvalue [see question 2.5] of type array-of-T which appears in an expression decays (with ========== < As a consequence of this definition, there is not really any --- > As a consequence of this definition, there is no apparent difference in the behavior of the "array subscripting" operator [] as it applies to arrays and pointers. In an expression of ========== the form a[i], the array reference "a" decays into a pointer, < following the rule above, and is then subscripted exactly as < would be a pointer variable in the expression p[i]. In either --- > following the rule above, and is then subscripted just as would > be a pointer variable in the expression p[i] (although the > eventual memory accesses will be different, as explained in > question 2.2). In either case, the expression x[i] (where x is an array or a pointer) is, by definition, exactly equivalent to *((x)+(i)). ========== > 2.5: How can an array be an lvalue, if you can't assign to it? > > A: The ANSI C Standard defines a "modifiable lvalue," which an > array is not. > > References: ANSI Sec. 3.2.2.1 p. 37. ========== > 2.8: Practically speaking, what is the difference between arrays and > pointers? > > A: Arrays automatically allocate space, but can't be relocated or > resized. Pointers must be explicitly assigned to point to > allocated space (perhaps using malloc), but can be reassigned > (i.e. pointed at different objects) at will, and have many other > uses besides serving as the base of blocks of memory. > > Due to the "equivalence of arrays and pointers" (see question > 2.3), arrays and pointers often seem interchangeable, and in > particular a pointer to a block of memory assigned by malloc is > frequently treated (and can be referenced using [] exactly) as > if it were a true array (see also question 2.13). ========== > 2.11: How do I write functions which accept 2-dimensional arrays when > the "width" is not known at compile time? > > A: It's not easy. One way is to pass in pointer to the [0][0] > element, along with the two dimensions, and simulate array > subscripting "by hand:" > > f2(aryp, m, n) > int *aryp; > int m, n; > { ... ary[i][j] is really aryp[i * n + j] ... } > > This function could be called with the array from question 2.10 > as > > f2(&array[0][0], NROWS, NCOLUMNS); > > See also question 2.14. ========== Q: How do I declare a pointer to an array? < A: Usually, you don't want to. Consider using a pointer to one of < the array's elements instead. Arrays of type T decay into < pointers to type T (see question 2.3), which is convenient; --- > A: Usually, you don't want to. When people speak casually of a > pointer to an array, they usually mean a pointer to its first > element. > > Instead of a pointer to an array, consider using a pointer to > one of the array's elements instead. Arrays of type T decay > into pointers to type T (see question 2.3), which is convenient; ========== < all. (See question 2.8 above.) When people speak casually of a < pointer to an array, they usually mean a pointer to its first < element. --- > all. (See question 2.10 above.) ========== 2.13: How can I dynamically allocate a multidimensional array? A: It is usually best to allocate an array of pointers, and then < initialize each pointer to a dynamically-allocated "row." The < resulting "ragged" array can save space, although it is not < necessarily contiguous in memory as a real array would be. Here --- > initialize each pointer to a dynamically-allocated "row." Here is a two-dimensional example: ========== With all of these techniques, you may of course need to remember < to free the arrays (which may take several steps) when they are < no longer needed. You must also be extremely cautious when < passing dynamically-allocated arrays down to other functions, if < those functions are also to accept conventional, statically- < allocated arrays (see question 2.8). --- > to free the arrays (which may take several steps; see question > 3.8) when they are no longer needed, and you cannot necessarily > intermix the dynamically-allocated arrays with conventional, > statically-allocated ones (see question 2.14 below, and also > question 2.10). ========== > 2.14: How can I use statically- and dynamically-allocated > multidimensional arrays interchangeably when passing them to > functions? > > A: There is no single perfect method. Given the array and f() as > declared in question 2.10, f2() as declared in question 2.11, > array1, array2, array3, and array4 as declared in 2.13, and a > function f3() declared as: > > f3(pp, m, n) > int **pp; > int m, n; > > ; the following calls would be legal, and work as expected: > > f(array, NROWS, NCOLUMNS); > f(array4, nrows, NCOLUMNS); > f2(&array[0][0], NROWS, NCOLUMNS); > f2(*array2, nrows, ncolumns); > f2(array3, nrows, ncolumns); > f2(*array4, nrows, NCOLUMNS); > f3(array1, nrows, ncolumns); > f3(array2, nrows, ncolumns); > > The following two calls would probably work, but involve > questionable casts, and work only if the dynamic ncolumns > matches the static NCOLUMNS: > > f((int (*)[NCOLUMNS])(*array2), nrows, ncolumns); > f((int (*)[NCOLUMNS])array3, nrows, ncolumns); > > If you can understand why all of the above calls work and are > written as they are, and if you understand why the combinations > that are not listed would not work, then you have a _very_ good > understanding of arrays and pointers (and several other areas) > in C. ========== < This technique, though attractive, is not strictly conforming to < the C standards (in spite of its appearance in Numerical Recipes < in C). --- > Although this technique is attractive (and is used in the book > Numerical Recipes in C), it does not conform to the C standards. ========== > 3.8: I'm allocating structures which contain pointers to other > dynamically-allocated objects. When I free a structure, do I > have to free each subsidiary pointer first? > > A: Yes. In general, you must arrange that each pointer returned > from malloc be individually passed to free, exactly once (if it > is freed at all). ========== > 3.9: I have a program which mallocs but then frees a lot of memory, > but memory usage (as reported by ps) doesn't seem to go back > down. > > A: Most implementations of malloc/free do not return freed memory > to the operating system (if there is one), but merely make it > available for future malloc calls. ========== 5.3: Does anyone have a tool for converting old-style C programs to ANSI C, or vice versa, or for automatically generating prototypes? > A: First, are you sure you really need to convert lots of old code > to ANSI C? The old-style function syntax is still acceptable. Two programs, protoize and unprotoize, convert back and forth ========== > 5.6: Why can't I pass a char ** to a function which expects a > const char **? > > A: You can use a pointer-to-T (for any type T) where a pointer-to- > const-T is expected, but the rule (an explicit exception) which > permits slight mismatches in qualified pointer types is not > applied recursively, but only at the top level. > > You must use explicit casts (e.g. (const char **) in this case) > when assigning (or passing) pointers which have qualifier > mismatches at other than the first level of indirection. > > References: ANSI Sec. 3.1.2.6 p. 26, Sec. 3.3.16.1 p. 54, > Sec. 3.5.3 p. 65. ========== "int func(x) float x;". Old C (and ANSI C, in the absence of prototypes, and in variable-length argument lists) "widens" < certain arguments when they are passed to functions. floats < are promoted to double, and characters and short integers are < promoted to integers. (The values are automatically coerced --- > certain arguments when they are passed to functions. Type float > is promoted to double, and characters and short integers are > promoted to integers. (The values are automatically converted back to the corresponding narrower types within the body of the ========== > 5.8: Why does the declaration > > extern f(struct x {int s;} *p); > > give me an obscure warning message about "struct x introduced in > prototype scope"? > > A: In a quirk of C's normal block scoping rules, a struct declared > only within a prototype cannot be compatible with other structs > declared in the same source file, nor can the struct tag be used > later as you'd expect (it goes out of scope at the end of the > prototype). > > To resolve the problem, precede the prototype with the vacuous- > looking declaration > > struct x; > > , which will reserve a place at file scope for struct x's > definition, which will be completed by the struct declaration > within the prototype. > > References: ANSI Sec. 3.1.2.1 p. 21, Sec. 3.1.2.6 p. 26, > Sec. 3.5.2.3 p. 63. ========== > 5.11: Is exit(status) truly equivalent to returning status from main? > > A: Yes, except under a few older, nonconforming systems. > > References: ANSI Sec. 2.1.2.2.3 p. 8. ========== > 5.16: Is char a[3] = "abc"; legal? What does it mean? > > A: Yes, it is legal; it declares an array of size three, > initialized with the three characters 'a', 'b', and 'c', without > the usual terminating '\0' character. > > References: ANSI Sec. 3.5.7 pp. 72-3. ========== 6.5: Does the sizeof operator work in preprocessor #if directives? A: No. Preprocessing happens during an earlier pass of compilation, before type names have been parsed. Consider using < the predefined constants in ANSI's <limits.h>, or a "configure" < script, instead. --- > the predefined constants in ANSI's <limits.h>, if applicable, or > a "configure" script, instead. (Better yet, try to write code > which is inherently insensitive to type sizes.) ========== > 6.8: I have some code which contains far too many #ifdef's for my > taste. How can I preprocess the code to leave only one > conditional compilation set, without running it through cpp and > expanding all of the #include's and #define's as well? > > A: There is a program floating around called unifdef which does > exactly this. (See question 17.8.) ========== > 6.9: How can I list all of the pre#defined identifiers? > > A: There's no standard way, although it is a frequent need. The > most expedient way is probably to extract printable strings from > the compiler or preprocessor executable with something like the > Unix strings(1) utility. ========== The obvious disadvantage is that the caller must always remember < to use the extra parentheses. (It is often better to use a --- > to use the extra parentheses. Another solution is to use > different macros (DEBUG1, DEBUG2, etc.) depending on the number > of arguments. (It is often better to use a bona-fide function, ========== > 7.4: I can't get the va_arg macro to pull in an argument of type > pointer-to-function. > > A: The type-rewriting games which the va_arg macro typically plays > are stymied by overly-complicated types such as pointer-to- > function. If you use a typedef for the function pointer type, > however, all will be well. > > References: ANSI Sec. 4.8.1.2 p. 124. ========== < The primary advantages of enums are that the numeric values are < automatically assigned, and that a debugger may be able to < display the symbolic values when enum variables are examined. --- > Some advantages of enums are that the numeric values are > automatically assigned, that a debugger may be able to display > the symbolic values when enum variables are examined, and that > they obey block scope. ========== > 10.2: What should the 64-bit type on new, 64-bit machines be? > > A: Some vendors of C products for 64-bit machines support 64-bit > long ints. Others fear that too much existing code depends on > sizeof(int) == sizeof(long) == 32 bits, and introduce a new 64- > bit long long int type instead. > > Programmers interested in writing portable code should therefore > insulate their 64-bit type needs behind appropriate typedefs. > Vendors who feel compelled to introduce a new long long int type > should advertise it as being "at least 64 bits" (which is truly > new; a type traditional C doesn't have), and not "exactly 64 > bits." ========== complete at the point where the "next" field is declared. To fix it, first give the structure a tag ("struct node"). Then, declare the "next" field as "struct node *next;", and/or move the typedef declaration wholly before or wholly after the struct < declaration. One fixed version would be --- > declaration. One corrected version would be ========== > 11.2: Why doesn't the code scanf("%d", i); work? > > A: You must always pass addresses (in this case, &i) to scanf. ========== > 11.3: Why doesn't this code: > > double d; > scanf("%f", &d); > > work? > > A: With scanf, use %lf for values of type double, and %f for float. > (Note the discrepancy with printf, which uses %f for both double > and float, due to C's default argument promotion rules.) ========== > 11.4: Why won't the code > > while(!feof(fp)) > fgets(buf, MAXLINE, fp); > > work? > > A: C's I/O is not like Pascal's. EOF is only indicated _after_ an > input routine has tried to read, and has reached end-of-file. > Usually, you should just check the return value of the input > routine (fgets in this case); feof() is rarely needed. ========== > 11.5: Why does everyone say not to use gets()? > > A: It cannot be told the size of the buffer it's to read into, so > it cannot be prevented from overflowing that buffer. ========== < It --- > A related problem is that unexpected non-numeric input can cause > scanf to "jam." Because of these problems, it is usually better to use fgets() to read a whole line, and then use sscanf or other string functions to pick apart the line buffer. ========== > 11.9: I'm trying to update a file in place, by using fopen mode "r+", > then reading a certain string, and finally writing back a > modified string, but it's not working. > > A: Be sure to call fseek before you write, both to seek back to the > beginning of the string you're trying to overwrite, and because > an fseek or fflush is always required between reading and > writing in the read/write "+" modes. > > References: ANSI Sec. 4.9.5.3 p. 131. ========== > 11.10: How can I read one character at a time, without waiting for the > RETURN key? > > A: See question 16.1. ========== > 11.12: How can I redirect stdin or stdout to a file from within a > program? > > A: Use freopen. ========== > 12.1: Why does strncpy not always place a '\0' termination in the > destination string? > > A: strncpy was first designed to handle a now-obsolete data > structure, the fixed-length, not-necessarily-\0-terminated > "string." strncpy is admittedly a bit cumbersome to use in > other contexts, since you must often append a '\0' to the > destination string by hand. ========== The comparison routine's arguments are expressed as "generic < pointers," void * or char *. They must be converted back to --- > pointers," const void * or char *. They must be converted back to what they "really are" (char **) and dereferenced, yielding ========== int pstrcmp(p1, p2) /* compare strings through pointers */ < char *p1, *p2; /* void * for ANSI C */ --- > char *p1, *p2; /* const void * for ANSI C */ ========== A: The conversions must be in the comparison function, which must < be declared as accepting "generic pointers" (void * or char *) < as discussed above. --- > be declared as accepting "generic pointers" (const void * or > char *) as discussed above. ========== < 12.4: How can I get the time of day in a C program? --- > 12.5: How can I get the current date or time of day in a C program? ========== time(&now); printf("It's %.24s.\n", ctime(&now)); < exit(0); --- > return 0; ========== A: You can call srand() to seed the pseudo-random number generator < with a more random initial value. Popular random initial seeds are the time of day, or the elapsed time before the user presses < a key. --- > with a more random initial value. Popular seed values are the time of day, or the elapsed time before the user presses a key > (although keypress times are hard to determine portably; see > question 16.9). ========== < A: Perhaps; perhaps not. The test succeeds if the two strings are --- > A: It is not particularly good style, although it is a popular idiom. The test succeeds if the two strings are equal, but its form suggests that it tests for inequality. ========== A: Make sure you're linking against the correct math library. For < instance, under Unix, you usually need to use the -lm option at < the end of the command line when compiling/linking. --- > instance, under Unix, you usually need to use the -lm option, > and at the _end_ of the command line, when compiling/linking. ========== by not including code to handle %e, %f, and %g. It happens that Turbo C's heuristics for determining whether the program uses floating point are insufficient, and the programmer must < sometimes insert a dummy explicit floating-point call to force --- > sometimes insert an extra, explicit call to a floating-point > library routine to force loading of floating-point support. ========== Posix systems). Under MS-DOS, use getch(). Under VMS, try the < Screen Management (SMG$) routines. Under other operating --- > Screen Management (SMG$) routines, or curses, or issue low-level > $QIO's to ask for one character at a time. Under other ========== A: Consult your system documentation, or ask on an appropriate system-specific newsgroup (but check its FAQ list first). Mouse < handling is completely different under the X window system than < it is under MS-DOS than it is on the Macintosh. --- > handling is completely different under the X window system, MS- > DOS, Macintosh, and probably every other system. ========== < determine this number in advance. Under Unix, the stat() < function will give you an exact answer, and several other --- > determine this number in advance. Under Unix, the stat call > will give you an exact answer, and several other systems supply ========== answer. You can fseek to the end and then use ftell, but this usage is nonportable (it gives you an accurate answer only under < Unix, and a guaranteed, but potentially approximate answer only < for ANSI C "binary" files). --- nonportable (it gives you an accurate answer only under Unix, > and otherwise a quasi-accurate answer only for ANSI C "binary" > files). ========== < F_FREESP. Under MS-DOS, you can sometimes use < write(fd, "x", 0). However, there is no truly portable --- > F_FREESP. Under MS-DOS, you can sometimes use write(fd, "", 0). > However, there is no truly portable solution. ========== > Other routines you might look for on your > system include clock() and gettimeofday(). The select() and > poll() calls (if available) can be pressed into service to > implement simple delays. On MS-DOS machines, it is possible to > reprogram the system timer and timer interrupts. ========== an awful lot about object file formats, relocation, etc. Under BSD Unix, you could use system() and ld -A to do the linking for < you. There is also a GNU package called "dld" which takes care < of some or all of this. See also question 7.5. --- > you. Many (most?) versions of SunOS and System V have the -ldl > library which allows object files to be dynamically loaded. > There is also a GNU package called "dld". See also question 7.6. ========== 17.3: How can I return several values from a function? A: Either pass pointers to locations which the function can fill in, or have the function return a structure containing the < desired values. See also questions 2.12, 3.4, and 9.2. --- > desired values, or (in a pinch) consider global variables. See > also questions 2.16, 3.4, and 9.2. ========== be possible at all. Read your compiler documentation very carefully; sometimes there is a "mixed-language programming guide," although the techniques for passing arguments and < ensuring correct run-time startup are often arcane. --- > ensuring correct run-time startup are often arcane. More > information may be found in FORT.Z by Glenn Geers, available via > anonymous ftp from suphys.physics.su.oz.au in the src directory. ========== < obtain a current copy of the rules and other information, send --- > obtain a current copy of the rules and guidelines, send e-mail ========== < {apple,pyramid,sun,uunet}!hoptoad!obfuscate or < obfuscate@toad.com --- > {apple,pyramid,sun,uunet}!hoptoad!judges (not the addresses for > judges@toad.com submitting entries) ========== Contest winners are first announced at the Summer Usenix < Conference in mid-June, and posted to the net in July. Previous < winners are available on uunet (see question 17.8) under the --- > Conference in mid-June, and posted to the net sometime in July- > August. Winning entries from previous years (to 1984) are > archived at uunet (see question 17.8) under the directory > ~/pub/ioccc. ========== > As a last resort, previous winners may be obtained by sending > e-mail to the above address, using the Subject: "send YEAR > winners", where YEAR is a single four-digit year, a year range, > or "all". ========== A: These generally mean that your program tried to access memory it shouldn't have, invariably as a result of improper pointer use, < often involving malloc. --- > often involving malloc (see question 17.17) or perhaps scanf > (see question 11.2). ========== > 17.17: My program is crashing, apparently somewhere down inside malloc, > but I can't see anything wrong with it. > > A: It is unfortunately very easy to corrupt malloc's internal data > structures, and the resulting problems can be hard to track > down. The most common source of problems is writing more to a > malloc'ed region than it was allocated to hold; a particularly > common bug is to malloc(strlen(s)) instead of strlen(s) + 1. > Other problems involve freeing pointers not obtained from > malloc, or trying to realloc a null pointer (see question 3.10). > > A number of debugging packages exist to help track down malloc > problems; one popular one is Conor P. Cahill's "dbmalloc". ========== < A: Plum Hall (1 Spruce Ave., Cardiff, NJ 08232, USA), among others, < sells one. --- > A: Plum Hall (1 Spruce Ave., Cardiff, NJ 08232, USA) sells one. > The FSF's GNU C (gcc) distribution includes a c-torture- > test.tar.Z which checks a number of common problems with > compilers. Kahan's paranoia test, found in netlib on > research.att.com, strenuously tests a C implementation's > floating point capabilities. ========== < open. There is one on uunet (see question 17.8) in --- > open. There is one (due to Jeff Lee) on uunet (see question > 17.8) in usenet/net.sources/ansi.c.grammar.Z (including a > companion lexer). Another one, by Jim Roskind, is in > pub/*grammar* at ics.uci.edu . The FSF's GNU C compiler contains a grammar, as does the appendix to K&R II. ========== which should keep it around all month. It can also be found in < the newsgroup news.answers . Several sites archive news.answers < postings and other FAQ lists, including this one; the archie < server (see question 17.8) should help you find them. See the < meta-FAQ list in news.answers for more information. --- > the newsgroups comp.answers and news.answers . Several sites > archive news.answers postings and other FAQ lists, including > this one: two sites are pit-manager.mit.edu (directory > pub/usenet), and ftp.uu.net (directory usenet). The archie > server should help you find others. See the meta-FAQ list in > news.answers for more information; see also question 17.8. ========== < This list is an evolving document, not just a collection of this --- > This list is an evolving document of questions which have been > Frequent since before the Great Renaming, not just a collection of this month's interesting questions. ========== > Thanks to Jamshid Afshar, Sudheer Apte, Randall Atkinson, Dan Bernstein, > Vincent Broman, Stan Brown, Joe Buehler, Gordon Burditt, Burkhard Burow, > D'Arcy J.M. Cain, Raymond Chen, Christopher Calabrese, Paul Carter, > James Davies, Jutta Degener, Norm Diamond, Ray Dunn, Stephen M. Dunn, > Bjorn Engsig, Alexander Forst, Jeff Francis, Dave Gillespie, Samuel Goldstein, Alasdair Grant, Ron Guilmette, Doug Gwyn, Tony Hansen, Joe Harrington, Guy Harris, Jos Horsmeier, Blair Houghton, Kirk Johnson, > Peter Klausler, Andrew Koenig, Tom Koenig, John Lauro, Felix Lee, Don > Libes, Christopher Lott, Tim McDaniel, John R. MacMillan, Evan Manning, > Barry Margolin, Brad Mears, Mark Moraes, Darren Morby, Landon Curt Noll, > David O'Brien, Richard A. O'Keefe, Hans Olsson, Francois Pinard, Pat > Rankin, Erkki Ruohtula, Rich Salz, Chip Salzenberg, Paul Sand, Doug Schmidt, Patricia Shanahan, Peter da Silva, Joshua Simons, Henry > Spencer, David Spuler, Erik Talvola, Clarke Thatcher, Wayne Throop, > Chris Torek, Goran Uddeborg, Wietse Venema, Ed Vielmetti, Larry Virden, > Chris Volpe, Freek Wiedijk, Dave Wolverton, Mitch Wright, Conway Yee, > and Zhuo Zang, who have contributed, directly or indirectly, to this article. Special thanks to Karl Heuer, and particularly to Mark Brader, who (to borrow a line from Steve Johnson) have goaded me beyond my inclination, and occasionally beyond my endurance, in relentless pursuit of a better FAQ list. ========== Steve Summit scs@adam.mit.edu scs%adam.mit.edu@mit.edu mit-eddie!adam.mit.edu!scs